什麼是替換原則呢？

1. 建構易於修改，最小化的變動成本的架構

   要理解LSP原則，要先回歸到原則要達到的核心目的，建構易於修改，最小化的變動成本的架構，LSP是管理有細微差異的模組的原則，這些模組之間應該是可以根據角色情境做替換的，先說結論，簡述一下SRP核心心法之一是提升內聚性，一個模組只對一個角色負責，當相關需求隨著開發逐漸變多，模組會越拆越細，會出現許多有著大致相同但有細小差異模組或類別，這時候應該遵循LSP替換原則，使用介面建立依賴關係，而非依賴所有模組

   假設今天建立一個以訂閱服務為核心的應用(ex.訂閱國際新聞的內容網站)，訂閱方案分為一般方案和黃金方案，現在到計算訂閱費的時間，應用程式“應該”要透過依賴介面為起手式，實踐LSP替換原則，例如有個方案介面，其中有計算訂閱金的方法，應用程式只要呼叫介面中的計算訂閱金的方法，就會自動根據訂閱方案計算出訂閱金，介面繼承了一般方案和黃金方案的類別，實作計算不同方案的訂閱金，架設明年預計推出一般方案2.0，那麼因為有遵守LSP，因此我們可以在最小變動下，透過介面更新繼承成一般方案2.0，而對原本使用介面實作計算訂閱金的應用不會有影響，相對應用直接依賴一般方案、黃金方案

違反LSP 會遭遇什麼風險呢？

1. 浪費更多時間在處理，不必要的麻煩，且複雜化系統，提高耦合

   書中舉例，假設我們開發一個計程車調度服務給各大計程車行使用，我們已經規範好了API介面，但因為一些特殊情況，導致某些特別的車行，使用不符合規範的格式串接，但還要要求功能正常運行，導致架構師需要花費大量心力去確保這個不守規則的車行能夠正常運作，而在架構師這麼做的時候，不僅浪費了成本在本就可以輕鬆避免的事情，且提高了耦合，墊高了後續維護成本，因為要確保這個特例可運作

   這邊我一開始串不起來，這樣做哪裡違反了LSP，後來自己的理解是，當特例車行使用不符合規範的uri串接服務時候，但我們卻依然想讓錯誤變正常時，就違反了LSP，因為已經違反在能夠彈性抽換子型態的原則，每一次變更都要符合這個特例，也與最小化維護成本的目標